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(54) Management of user profile data 



(57) The invention generally relates to the field of 
mobile multimedia middle-ware, computer networking, 
distributed processing systems, data bases, hand-held 
computers and wireless communication. A method for 
conveniently managing user profile information in an 
unified instant messaging system (7) is proposed. This 
method operates on a data base structure, which ac- 



commodates in a flexible way subscribers' information. 
More specifically, this method takes into account the 
mutable characteristics of the environment where sub- 
scribers' devices (9) are operating: subscribers can in 
fact freely modify their personal user profiles (1 ) as sit- 
uations change and/or as they move to different geo- 
graphical locations. 



FIG 7 



<<domain>> 
1MB Service Provider 



IMs may eventually be generated 
directly at the user side 



Instant Message 



W — 



Multimedia Flow/Stream 



i. 



User Profile DB 



0. 



1MB Account 



+ Act ive Contexti ndi cato r : UserProfile 



Billing; 



CD 
00 

o 

CO 



Accounting DB 

n 



o.; 



User Account 



1 



1„* 



User Profile 
Space 



1 



Default User 
Profile 



0 



Token — 



Extended User 
Profile 

57i 14 1 

.1 "" J — 



0. 



5 



Subscription 
Contract 



Active 
Context 



User Profile 
TT 



1..* 



Current 
Terminal 



Terminal 
Device 



LU 



Printed by Jouve, 75001 PARIS (FR) 



EP 1 130 869 A1 



Description 

[0001 ] The present invention relates to a data base for storing and managing user profile data, to a software program 
for implementing such a data base, to a method for managing a user profile data base as well as to a software program 

5 for implementing such a method. 

[0002] Why are people investing so much time and money in telecommunication? Mainly for two reasons: (i) to be 
more time-effective (i.e. saving time) and (ii) to be omnipresent (i.e. being reachable everywhere at any time). Modern 
telecommunication tech nologies - like telephone, fax, mobile phones, and the Internet - address these issues by offering 
a wide spectrum of services. Combined together, these services effectively help individuals saving time and even 

10 reducing cost. These various network- based services typically provide users with specific Quality of Service (QoS)- 
constrained functionality. 

[0003] Unified Messaging Systems (UMS) bridge the gaps between the different communication means, by merging 
analog and digital messages - such as facsimile, voice mail, e-mail, WWW, and the cell phone short message service. 
In particular, one can distinguish among (i) messages such as facsimile or voice mail (which in principle may be sent 
15 over an analog telecommunication network) and (ii) digitally generated, processed and transmitted messages. Besides 
sheer homogeneous transmission, heterogeneous analog/digital messaging applications are also conceivable (e.g. 
voice mail, voice recognition with e-mail transfer, fax-to-data, data-to-fax). 

[0004] Today's UMS allow messages to be originated, received, processed, transmitted, and stored independently 
of their type. This approach allows users to exploit different network services in a unified and integrated way. For 

20 example, a phone call, recorded as a voice message in a voice mailbox, can be sent to the recipient as an E-mail 
attachment. Future progress in voice recognition might even enable high-quality conversion of voice attachments into 
text. To summarize, UMS copes with the heterogeneity of different network-based services, by addressing message 
format conversion issues. UMS thus offer a seamless fabric, over which users can communicate by using whatever 
terminal device is available at hand. 

25 [0005] A typical UMS drawback is the lack of support for timely information delivery: UMS rely upon the underlying 
network services to reach recipients on time. In order to solve this problem, Unified Instant Messaging (UIM) systems 
have been devised so as to allow messages to be sent in near real time between users. For achieving this goal, UIM 
systems have to take into account the inherent QoS characteristics of the underlying network service. Furthermore, 
UIM systems heavily rely upon mobile communication for interacting, with roaming service users. When taking into 

30 account all these new issues, the original problem domain can be broken down into two new problem sub-domains: 
(i) user mobility and (ii) context-awareness. 

[0006] User mobility describes the ability of the user to move between different terminals (e.g. from the office desktop 
PC to the laptop at home). This differs from the terminal mobility case where the terminal moves without losing the 
connection to the network. The terminal devices must then cope with either horizontal handover between different cells 
35 of a given cellular network (relying on mobility management functions within the network) or vertical handover between 
different networks (e.g. an indoor LAN and the outdoor public networks). 

[0007] As for context-awareness concerns, the UIM service must take into account the capabilities of the terminal 
and the limitations of the used network service. For example, using the GSM phase 2+ Short Message Service (SMS), 
the UIM service can only transmit up to 1 60 characters. Therefore, when using the SMS service, the UIM has to reduce 

40 the amount of data transmitted (by either only transmitting certain portions of the original message, or by just signaling 
the availability of the Instant Message to the user). Future developments of mobile data services (e.g. the introduction 
of packet switching like the GSM GPRS system or the 3 rd generation system) will allow users to exploit an even broader 
range of services. In such a case, the UIM system will have to select the network service with the best quality/price ratio. 
[0008] UIM systems addressing these two aspects de facto offer users a new type of service. This kind of service - 

45 as of this writing - is not part of any available Internet and/or (mobile) telecommunication service operators' offer. 

[0009] Given that the UIM Service involves information brokerage functionality, the UIM system has been called 
Instant Message Broker (1MB). The 1MB System has been designed to provide a flexible and extensible UIM service 
that can effectively scale up to a large user community. 

[0010] For clarity, in order to distinguish between unified instant messaging (UIM) and unified instant messages, the 

50 latter are thereinafter referenced as I Malls. 

[0011] The 1MB System can either be added to an existing infrastructure or be used as an independent value-added 
service. Existing infrastructures could be either the ones offered by Internet Service Providers (ISP) or those provided 
by cellular phone operators. In such a case, the 1MB system has to provide well-defined interfaces to external systems 
(such as the user database or the billing systems), managed by the involved third parties. In the case of a standalone 

55 value-added service, offered by an 1MB Service Provider, the 1MB system uses the same interfaces to its own infra- 
structure components. 

[0012] The UIM service - is offered by an 1MB Service Provider, which manages an 1MB System. The 1MB System 
is the physical realisation of the UIM service. The 1MB System is a distributed processing system that integrates network 



2 



EP 1 130 869 A1 



technologies like PSTN, IP. and Mobile Telecom Networks for (i) allowing users to access its functionality, (ii) accom- 
plishing its tasks, and (iii) delivering the processed information to the called parties. 

[0013] From a business viewpoint, 1MB Systems offer services to registered users (thereinafter, the subscribers). 
Subscription can be provisioned either privately, or through the mediation of an organisation which allows its members 

5 to access the 1MB service. 

[001 4] Figu re 2 depicts the actors involved i n the U I M service (Organisation, Users Community, 1MB Service Provider) 
and the resources required for accomplishing the service's goals (1MB System, PSTN, IP, and Mobile Telecom Net- 
works). The Users Community is the set of 1MB service subscribers, which can be further classified either as private 
users or as organization members. The latter are part of Organisations, i.e. actors that have the authority to establish 

10 personal 1MB service accounts on behalf of a chosen subset of their members. This delegation schema can also be 
used to grant 1MB service access to the subscriber base of an ISP or network operator. 

[0015] The primary purpose of instant messaging is the transmission of arbitrary high priority information as a mes- 
sage in (nearly) real-time. Instant messages can be originated and received from various devices such as cell phones 
(GSM Short Message Service), PDAs (Personal Digital Assistants), e-mail, WWW, facsimile or voice mail. Additionally. 
15 instant messages contain functionality for alert generation, message privacy, and payment. A unified instant message 
can include: 

• message data (text and multimedia data) 

20 • actions, for example the generation of an alert notification, 

• message privacy (RSA), 

• authentication of message originator and content (Keyed-Hashing Message Authentication). 

25 

• geographical information, limited message durability 

[0016] The 1MB service performs the following steps: (i) receives a message from a subscriber, (ii) transforms mes- 
sage according to the user preferences, and (iii) delivers the transformed information to the recipient's preferred terminal 
30 device. The process must take timing constraint into account for ensuring fast and near real-time processing and 
delivery. 

[0017] The 1MB svstem (see Fig. 1) consists of four major components all implemented f.e. in Java : 

1 . Instant Message Gateway (MG) 4 - converts arbitrary messages (GSM/SMS, email, FAX, WWW) into/from 
35 IMails; 

2. Message Brokers (MB) 3 - manages client address conversion, User Profile handling, IMail routing, security 
and accounting; 

40 3. Processing Units 2 - provide capabilities for modifying message content; 

4. Subscribers' Information Repositories 1 - contains personal information and accounting records. 

[0018] The 1MB system has been developed according to the Open Distributed Processing (ODP) standards. Figure 
45 3 presents a logical view (the ODP Computational Viewpoint) of the 1MB System. In that picture, circles indicate logical 
computational objects, rounded-angle boxes stand for connection abstractions, and double crossed arcs represent the 
interfaces between objects. 

[0019] Subscribers may use different types of frontends for accessing 1MB services. As indicated in the picture, one 
possible frontend is an Internet browser, which forwards the message to a message gateway via a Web server (Web 
50 Service). Other frontends might directly communicate with message gateways. 

[0020] Originating Message Gateways (OMG) receive messages in various forms (GSM/SMS, E-mail, Telefax, etc.) 
and convert them into IMails. Destination MG (DMG) offer the inverse functionality sending messages directly to the 
user. 

[0021] OMG must ensure the authenticity of the IMail. The Web Service based frontend might request the user to 
55 perform a login procedure. Other frontends might accomplish user authentication through digital signatures or through 
other authenticating procedures. 

[0022] Within the 1MB system IMails are transmitted in nearly real-time over secure TCP/IP connections. The MB 
performs the message brokering tasks. The 1MB Profile Database contains information aboutthe currently used terminal 
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and a list of preferred terminals/transmission modes, which can be used alternatively to reach the given subscriber. 
Depending on the selected transmission method, the MB decides to include additional processing steps, determines 
the required address information and selects a Destination Message Gateway (DMG). MB is also in charge of some 
bookkeeping activities like updating the Accounting DB. A DMG finally transmits the IMail to the recipient, according 
5 to the addressing information received from the MB. In the case of networks capable of acknowledging message 
delivery, DMG will transmit this information back to the MB. 

[0023] The 1MB System provides subscribers with several ways of accessing the UIM service. Following are listed 
alternative frontends: 

10 1 . Web-interface - allows a subscriber using a desktop to directly send an IMail to another subscribers; 

2. Mobile phone - can be used for sending SMS, which are then converted into I Mai Is; 

3. Command-line tool - enabling scripts (e.g. a resource monitoring daemon process) to automatically send event 
15 stamps to administration personnel; 

4. E-mail tool - for filtering, redirecting and/or forwarding incoming E-mails as IMails; 

5. Calendar tool - for sending notifications about upcoming appointments or birthdays to the user. 

20 

[0024] To provide scaleable and dynamically extensible service access, the tools use different types of gateways to 
access the service. Specialized 1MB gateways concentrate on providing a cost-effective interface to a specific network 
service. Message gateways can be dynamically created and plugged into the system. 

[0025] The 1MB System can optionally use distributed processing units for performing intermediate IMail processing. 
25 These units are invoked after the 1MB has retrieved the recipient's profile . 

[0026] The IMail processing step converts one IMail object into another IMail object with the processed content. The 
processing steps might perform: 

1. Message Content Enhancement 

30 

[0027] 1MB subscribers can force the 1MB System to include additional content in incoming IMails. Such additional 
information (like weather forecast, news headlines, etc.) can be offered to 1MB subscribers, following different criteria 
(e.g. for free, on a subscription basis, on-demand basis). 

35 2. Message Format Transformation 

[0028] In this processing step the coding format of the instant message is changed. This might include transcoding 
from one format to another (e.g. from one image, format to another or from a document format to Postscript). This kind 
of transformation might be applied if the target terminal can only process a limited number of message formats. Usually 
40 the information presented to the User and the media used for presentation remain unchanged. 

3. Message Content Reduction 

[0029] This process applies when the target device is not capable of handling large messages, or when the perceived 
45 network QoS is not sufficient to properly transfer the IMail. Content reduction is lossy, insofar as part of the original 
information may be lost. 

4. Message Interpretation 

so [0030] The 1MB concept can be extended to allow subscribers to include meta-information into their IMails. This 
m eta- information contains commands, which are processed by the 1MB System. As example , the "translate :Eng :Ger 
hunter" command would force the 1MB System to dispatch a Language Translation Processing Unit to translate the 
English word "hunter" into the German word "Jager". 

55 5. Actions 

[0031] The commands described in the previous point can be even used to steer specific devices, either at the 
customer premises or, remotely, in a different location (e.g. one could easily create a plant control systems by using 



EP 1 130 869 A1 



the 1MB system as a networking media, gluing sensors, controllers, and actuators). Another example would be the 
integration of 1MB Systems with home automation systems [5]. 

Message Delivery 

5 

[0032] IMails are delivered to the recipients through DMGs. As with incoming message gateways, each outgoing 
gateway is tailored to a specific network technology. When delivering the IM ail to the user, the message gateway can 
perform additional user authentication steps in orderto ensurethatthe target user is securely identified. In some cases, 
the message gateway must provide additional conversion steps to change the IMail to the format required by the 

10 networking service. For example, not all ASCI I characters can be transmitted by the GSM SMS service. As aforemen- 
tioned, some network technologies provide feedback, which indicates that a message was delivered to the end-user's 
terminal (e.g. the GSM SMS service). That feedback can be sent back to the MB, where it might be logged. 
[0033] Since MGs are the 1MB System interfaces with the real world, they feature a modular architecture, which 
enables 1MB Service Provider to rapidly update their equipment as soon as new telecommunication technologies are 

15 made available. This goal is achieved by structuring the MG as af ramework, whose core provides common fu nctionality. 
which accommodate - technology-specific protocol conversion modules (e.g. SMS driver), as a sort of plugins (see 
Fig. 4). 

Message authentication and privacy 

20 

[0034] Message authentication allows the communicating parties to ensure that the sent and received messages 
(as well as the true and alleged originator) are identical. The 1MB system uses the Keyed-Hashing for Message Au- 
thentication Code (HMAC) with MD-5 cryptographic hash function. HMAC is described in RFP 2104 and has been 
chosen for IP security, such as Transport Layer Security (TLS, soon to replace SSL) and Secure Electronic Transaction 
25 (SET). In contrast to symmetric block ciphers, cryptographic strong hash functions do not underlie application or export 
restrictions. Message encryption is not implemented yet. We favorite the public-key cryptography based on the RSA 
algorithm. 

Example 

30 

[0035] To summarize what described so far, Fig. 5 illustrates as an example how the 1MB System behaves in response 
to a subscriber's request (via a web- interface) to deliver a text message as a SMS to the Called Party. 
[0036] It is the object of the present invention to modify the above-captioned instant messaging approach for an 
environment with mutable characteristics. Those mutable characteristics can arise from the fact that the subscribers 
35 can in fact freely modify their personal user profiles as situations change and/or as they move to different geographical 
locations. 

[0037] The above-captioned object is achieved by means of the features of the independent claims. The dependent 
claims develop further the central idea of the present invention. 

[0038] According to the present invention therefore a data base for storing and managing user profile data is provided. 
40 The user profile data represent sets of user's information, and/or user preferences concerning the terminal devices 
users have access to, within information transmission network. The data base comprises respectively for each user 
at least one customisable user profile which can be created, edited and/or deleted by the user. Each customisable 
user profile is associated with an environment of the user representing a physical location and/or a logical context of 
the user. 

45 [0039] The data base can comprise a plurality of user profiles for one user, wherein only one user profile of a user 
is active at the same time. 

[0040] Each subscriber can have a plurality of User Profiles in a so-called User Space, which is the subscriber's own 
data space, as provisioned within the aforementioned User Profile Database. 

[0041] User Profiles can be totally independent from one another, or correlated. In the latter case, User Profiles can 
50 be considered as nodes of a graph, where the directed arcs represent logical links chaining User Profiles in an ordered 
manner. 

[0042] Each directed, open-loop path is hereby defined as a Context. 

[0043] Specific User Profiles (thereinafter indicated as Front-End Set Profiles, or simply FES) are defined as con- 
taining the description of a set of front ends. When FESs are not correlated each other, each Context simply chains 
55 one FES and one or more User Profiles. 

[0044] The User Profile chaining mechanism, can be used for efficiently extending the information conveyed by a 
pre-existing User Profile (or a chained set thereof), with additional new ones, by following an inheritance scheme. 
[0045] This inheritance scheme can be eventually extended to include User Profiles not belonging to the sheer given 
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User Space, rather being available to all (or a set of) subscribers. This scheme implements the concept of shared 
information. 

[0046] The aforementioned graph is topologically equivalent to a non-loop free tree structure, where the root repre- 
sents the overall 1MB system default configuration. 
5 [0047] User Spaces are non-loop free sub-trees of the aforementioned general tree. Within the User Space scope, 
the sub-tree root coincides with the subscriber's User Profile that contains subscriber's personal information. From this 
User Profile, all the other chained ones default to. In this case, each tree branch (a loop-free directed path, connecting 
some nodes of the given sub-tree - not to be confounded with the sub-tree concept) represents a Context projection 
onto the given User Space. 

w [0048] The aforementioned concepts are hereby described in terms of what described in the MASE Profile patent. 
More specifically, a User Profile is a Card, a Context is a set of Cards, and the order applied to the Context is the so- 
called search order. 

[0049] One or a plurality of presence token for each user can be provided, each presence token representing the 
availability of a user to receive copies of incoming instant messages at one of the terminal devices configured in the 
15 given User Profile. 

[0050] The User Space is associated with a special User Profile, the so-called Default User Profile, which contains 
subscriber's personal information and (as an option) service specific information. This User Profile can be created and 
deleted only by the User Profile Database administrator. Subscribers can only partially modify their own Default User 
Profile. 

20 [0051] The hierarchical scheme of the user profiles can be like a tree, the default user profile being the route of the 
tree. 

[0052] A priority information can be associated with each terminal device of a user profile. 

[0053] The data base can contain information on the access network, the network address and the characteristics 
of each terminal device. 
25 [0054] A mnemonic for the user can be attributed with each terminal device. 
[0055] A unified name can be attributed with each user. 
[0056] The data base content can be stored in cards in a distributed fashion. 
[0057] A user can directly enquire and counting information. 

[0058] According to a further aspect of the present invention a software program is provided implementing, when 
30 loaded in the memory of a computing device in a network environment, a data base according to as set forth above. 
[0059] According to a still further aspect of the present invention, a method for managing a user profile data base 
for storing user profile data representing the sets of terminal devices of users in an information transmission network 
is provided. The data base comprises for each user a set of User Profiles which can be created, edited and/or deleted 
by the user (with the exception of the Default User Profile, which the subscribers can only partially update), wherein 
35 each customisable user profile is associated with an environment of the user representing a physical location and/or 
a logical context of the user. 

[0060] The data base can comprise a plurality of user profiles for one user, wherein only one user profile of a user 
is active at the same time. 

[0061] According to a still further aspect of the present invention a software program for implementing, when loaded 
40 in the memory of a computing device in a network Environment, a method as set forth above is provided. 

[0062] In order to meet the time constrains of UIM systems, the 1MB system has to determine whether the 1MB user 
can be reached online or through other fast transmission means. 

[0063] Therefore, the 1MB System maintains 1MB subscribers' information in an 1MB User Profile Database. Each 
1MB subscriber is assigned a User Space, where custom information is organized in a set of User Profiles. This set is 

45 thereinafter indicated as Context. The user can define different Contexts for different situations and dynamically switch 
between them. At any given time, only one of the Contexts contained in the User Space is actually used by the 1MB 
System. Such Context is thereinafter referred to as Active Context The User Space maintains an Active Context Indi- 
cator, defining the currently used Context. At any time, the user can switch to another context (Context Switch). The 
use of mnemonic names for each User Profile and Context greatly improves the usability aspects of this mechanism. 

so [0064] The currently used Active Context fully describes how the subscriber can be reached. This includes an indi- 
cation whether the user is currently online on the preferred terminal device and in addition a set of alternative terminal 
devices, where the given 1MB subscriber might be contacted when not being reachable at the preferred one. These 
alternative terminal devices can be also used for receiving additional copies of instant messages. Besides this infor- 
mation, the user profile contains information about each terminal. The following Context information is used during the 

55 message brokering: 

1 . online - indication whether the user is currently online 
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2. Preferred terminal device - the terminal where the user is currently working 



3. Priority list- indicates the order the 1MB System shall follow for selecting terminal devices: high-priority terminal 
devices are to be selected first. If the selected terminal device is not available at the moment, the 1MB System 

5 shall select another device with the same or immediately lower priority (fallback mechanism). 

4. Presence Tokens- The number of purchased presence tokens, and the number of tokens (out of the purchased 
one), which the subscriber actually wishes to use at any given time. 



10 [0065] For each terminal, the MB can retrieve the following information: 



1 . network type - specifies through what telecommunication media and/or Service Provider the 1MB System can 
contact the selected terminal device. The network type includes QoS information required to determine the time- 
liness of information delivery through this network. 
15 network address - specifies how the 1MB System can contact the addressed terminal device through the given 

network. 



2. terminal device characteristics - the 1MB System uses this attribute for selecting the proper information format 
conversion mechanism, which is required for delivering information in a ready-to-use form to the Called Party's 
20 preferred terminal device. 



[0066] For administrative and management purposes, each terminal device listed in a User Profile is associated with 
a mnemonic (name), which allows humans to easily refer to any terminal device. Moreover, User Spaces contain 
additional subscribers' custom information, such as public keys (used for message privacy), buddy-lists, usage statis- 
ts tics, etc. 

[0067] The user can manipulate his profile through different means like a Web-based user interface, SMS, or a client 
application. This allows to define the currently used devices and to define different profiles for different situations. 
Anytime the current active context indicator can be switched to another profile. 

[0068] Further aspects, features and advantages of the present invention will become clear for the man skilled in 
30 the art when reading the following detailed description of the present invention taken in conjunction with the figures of 
the enclosed drawings. 

Figure 1 shows the basic architectural components of a unified instant messaging system, 

35 Figure 2 shows a unified instant messaging surface from a business view point, 

Figure 3 shows an instant message broker from a computational view point, 

Figure 4 shows an instant message gateway with protocol interface modules, 

40 

Figure 5 shows an information flow across the instant message broker system, 

Figure 6 shows the context and functional decomposition of an instant message broker account management, 

45 Figure 7 shows details of the instant message broker data bases from an information view point, 

Figure 8 shows a global view of the instant message broker account management functionality from a computa- 
tional view point, 

50 Figure 9 shows details of the instant message broker system from a computational view point, 

Figure 10 shows an enhanced profile structure, 

Figure 11 shows an incomplete example of the data model (UML Class Diagram), 

55 

Figure 12 shows the mapping of the reference data model to the EMPP, 

Figure 13 shows an example of an instant message broker mutable environment, 
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Figure 14 shows details of the core message gateway system from an engineering view point, 
Figure 1 5 shows details of the message broker core from an engineering view point. 
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[0069] This invention generalises the 1MB concept by dealing with a mutable environment rather than the static one 
addressed by the original 1MB invention. In a mutable environment the context, in which the user interacts with the 1MB 
system, can change overtime. 

[0070] Environment mutability can originate from two independent causes: (i) the set of terminal devices that 1MB 
service subscribers use for being reachable through such service, may change overtime (e.g. users can change mobile 
telephone Service Provider); (ii) subscribers may travel. In the latter case, subscribers may reach locations where 
some of their terminal devices are not available at a hand (e.g. a Telefax machine) and/or additional devices may be 
offered at better quality-price ratio (e.g. Voice-mail devices). 

[0071] These factors shall therefore been taken into account in the I MB system design phase, by allowing subscribers 
to change their original User Profile information at any time and in the most convenient way 

[0072] Moreover, subscribers may find useful to store certain information configuration for later use. For instance a 
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business man who frequently stays at a certain hotel while visiting a certain location, should be able to instantly change 
its IMB User Profile information to a pre-stored one, which already takes into account hotel facilities. Subscribers shall 
be able to perform this selection by simply using a human-comprehensible mnemonic for identifying the custom 1MB 
User Profile. 

5 [0073] This feature would alleviate subscribers' usage of IMB services, by avoiding repeating common interactions 
with the IMB system for changing User profile information. 

[0074] Additionally, this invention offers a subscriber a fast way of inquiring IMB services accounting information. 
[0075] Reasons for providing all these features are: 

10 • automatic changes: the IMB System can be automatically instructed how to reach the subscribers at their most 
convenient terminal device (or set of devices), as soon as the mutable environment changes, 

• this feature is particularly of interest when addressing Mobile Ad-Hoc network issues. 

15 • easy changes: IMB subscribers shall be able to interact with the IMB system in an user-friendly way (e.g.. the use 
of custom mnemonics), as for maintenance and administrative purposes. 

[0076] Both the Intelligent Network and TINA standards focus on similar issues, but they are both limited to the 
telecommunication world (e.g. IN Call Forwarding and Call Redirection services). Actually, the TINA approach is moving 
20 Carriers' focus from sheer telephone services to multimedia ones, but this standardisation effort has not yet gained 
momentum in the telecommunication marketplace, as of this writing. Furthermore, TINA deals with more complex 
scenarios compared to the IMB Service, and does not explicitly leverage existing World Wide Web (WWW)-based 
services, mobile multimedia applications, and hand-held computing devices, wireless connected to the WWW. 

25 Introduction 

[0077] The context of a mutable IMB environment is depicted in Figure 6, where a high level functional decomposition 
is also presented (by early introducing ODP Engineering Viewpoint concepts, that will be elaborated in later para- 
graphs). 

30 [0078] A suite of SW units is distributed over the set of HW entities that concur to build up the IMB system. These 
SW units co-operatively perform their tasks, in order to allow IMB subscribers to manage their IMB Profile and Ac- 
counting information. 

[0079] More specifically, these SW units consist of IMB Account Management Client and Server units. The Client 
unit serves as a front-end for subscribers who wish to access their IMB User Profile and Accounting information. The 
35 latter unit contains the IMB Account Management core functionality, and is in turn decomposed into multiple HW units, 
which are collocated in the IMB Message Gateways (MG), in the IMB Message Brokers (MB), in the IMB User Profile 
Database, and in the IMB Accounting Database. 

Notes about the IMB User Profile Database 

40 

[0080] Actually, the IMB User Profile Database HW Unit is indicated in Figure 6 simply as User Profile Database 1, 
and it is placed outside of the ellipse identifying the IMB System 7. This figure proposes in fact a separation between 
the User Profile Database 1 and the IMB System 7, insofar as the information managed by such database can con- 
veniently be used by other systems, which might rely on it for providing their services. 
45 [0081] The major advantage offered by the standalone User Profile Database approach, is in fact the availability to 
retrieve the current state of a subscriber at any given time, in terms of which terminal device (and what alternative 
terminal devices) the subscriber is currently reachable on. 

[0082] This kind of information can be compared to a dynamic phone directory (white pages), a mechanism that is 
addressed for instance by IN standardisation bodies for defining the Number Portability service (restricted to the sheer 
50 telecom arena). 

[0083] The IMB System 7 relies upon a Unified Naming convention for uniquely identifying IMB subscribers. By 
following the aforementioned approach , this topic can be therefore moved out of the sheer IMB System context, to the 
more general User Profile Database 1 . 

[0084] As in the IN Number Portability case, users can register with the User Profile Database 1 for obtaining a 
55 Unified Name (UN), and store there any information that might be necessary whenever subscribing special services, 
like IMB User Profile information in the case of the IMB service. In such case, Unified Names can be used also for 
properly accessing the IMB Accounting Database 8. 

[0085] This invention presents a common database structure that can be effectively used for storing, general context- 
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aware information in the User Profile Database 1 , whereas Unified Naming issues are described in more detail later on. 
The Method 

5 [0086] This paragraph introduces the hereby-proposed method from a logical perspective, by describing: 
=> the logical data structure model (described at the ODP Information Viewpoint level); 

^>the logical operations that can be used to manipulate such data (described at the ODP Computational Viewpoint 
10 level). 

[0087] Figure 6 represents both the context of a mutable 1MB environment and a high level functional decomposition, 
where the major aforementioned SW Units are indicated as placed in 1MB System HW Units and in the User Profile 
Database and Database Management System HW Units. 
15 [0088] Figure 7 offers a detail of the 1MB System ODP Information Viewpoint, with respect to the 1MB Databases. 
The graphical notation used is the UML. This figure graphically summarises at a high level the data structure as de- 
scribed. 

[0089] Figure 8 offers an ODP Computational Viewpoint of the overall 1MB System, where circles indicate logical 
computational objects, rounded-angle boxes stand for connection abstractions, and double crossed arcs represent the 
20 interfaces among the various objects. The front-end functionality can accommodate both the 1MB Service Access and 
the 1MB Account Management Client Unit. 

[0090] In this figure, the ISP Profiles DB and ISP DB Connection bubbles indicate a possible case where the 1MB 
System can verify 1MB subscribers' identities by simply relying on a third party's DB (an Internet Service Provider, in 
the case shown). There can be several other possibilities for achieving the same purpose (i.e. accessing subscriber 
25 authentication information^ e.g. by using a GSM Operator DB, or an 1MB Service Provider own DB (which can coincide 
with the 1MB Accounting DB). 

[0091] With respect to the UML Class Diagram presented in Figure 7 and the Computational Viewpoint diagrams 
depicted in Figure 8 and in Figure 9, the proposed method offers the following, features: 

30 1 . it provides 1MB subscribers with an 1MB Service User Space: 

• an 1MB Service User Space groups the Default User Profile (originally created at subscription time) with zero 
or many Extended User Profiles; 

35 • Extended User Profiles are stored, pre-configured User Profiles that can be used in substitution of - and/or in 

integration with the Default one; 

• the Default User Profile can be changed, queried, but not deleted, whereas the Extended User Profiles can 
be created, changed, queried, and deleted: 

40 

♦ as aforementioned, Default User Profile is created only once at subscription time by the 1MB Service 
Provider; 

♦ similarly, only the 1MB Service provider can accomplish Default User Profile deletion. When this happens, 
45 actually the whole given subscriber's User Space is de facto deleted; 

♦ this invention therefore addresses these issues by introducing different levels of authorisation in the 1MB 
Account Management functionality; 

50 • for efficiency purposes, Extended User Profiles can always default (if necessary) to Default User Profile infor- 

mation and shared User Profile information (thus avoiding information replication); 

• such hierarchical scheme can be further extended recursively, thus leading to the conclusion that the 1MB 
Service User Space is topological^ equivalent to a non-loop free directed graph. Within a User Space scope, 

55 such a graph assumes a non-loop free tree topology, where the root node coincides with the Default User 

Profile. 

2. It offers the concept of Active Context: at any given time, only one of the User Contexts is effectively used by 
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the 1MB system; all the others can be considered as being in a stand-by state: 

• subscribers can switch at run time from one Active Context to another one (Context Switch). This operation 
is accomplished by simply updating an Active Context Indicator, which is part of the User Space and maintains 
a reference to the Context currently used as Active Context; 

• any change to the Active Context (including Context Switch) takes place in mutual exclusion with respect to 
the normal MB routing activity. Changes to any other stand-by profile can be performed concurrently with 
respect to the normal MB routing activity. 

3. It allows 1MB subscribers to directly inquire MB User Profile and Accounting information 

• inquiry results are sent to the subscriber by using plain 1MB functionality (e.g. Accounting information can be 
sent to the inquirer as a SMS message, if so preferred by the subscriber, according to his/her User Profile). 

4. It allows 1MB subscribers to update 1MB User Profile information. 

• updates can be committed back to the User Profile being changed, or to a fresh new one: 

♦ new (Extended) User Profiles can be created by simply storing only the neiv information, (which can result 
brand new to the 1MB system, and/or may override pre-existent one): for this reason, new Extended User 
Profiles logically refer to previous information. This reference scheme is offered by the aforementioned 
logical directed graph structure of the 1MB User Space. This to underlinethat no information cloning mech- 
anism is used whatsoever. 

5. It allows subscribers to signal their availability at a certain terminal device, out of the set of terminal devices 
configured in the Active Context. 

• subscribers' availability at one or more terminal devices is bound to the concept of presence token, which the 
1MB system uses for selecting the proper terminal device where to route messages; 

• in the (normal) case of a multiplicity-one token, there is only one presence token, which the user can logically 
move from one device to another; 

• in the case of a multiplicity-n token, the subscriber can freely and independently signal his/her availability at 
multiple terminal devices, up to a maximum number equal to n. The multiplicity greater-than-one service is 
envisioned to be an optional feature that subscribers can obtain at an additional charge. 

6. Subscribers can accomplish all the aforementioned management operations by using a front-end device. This 
entity provides a secure connection to the 1MB System, which is in charge of: 

6.1 verifying subscriber authentication (through either the mediation of a Web Server or directly the Message 
Gateway functionality); 

6.2 determining subscriber authorisation level (e.g. through the Message Broker functionality, based on the 
information contained in the User Profile and/or Accounting Database); 

6.3 fulfilling subscriber requests and communicating back the results to the subscriber (e.g. through the Mes- 
sage Broker functionality, based on the information contained in the User Profile and/or Accounting Database). 

[0092] As will described in more detail in the following paragraphs, such functionality is broken into multiple SW units. 

The Implementation of the Method 

[0093] The following paragraphs describe the mapping from the logical model (ODP Information and Computational 
Viewpoints) to the implementation of it (ODP Engineering and Technology Viewpoints. 

[0094] First of all, the logical data structure presented in the previous paragraph is mapped to an extended version 
of the Profile concept. 
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[0095] Following is the description of the physical realisation of the aforementioned ODP Computational Viewpoint 
model, in terms of SW and HW units, with respect to the original 1MB system architecture. 

The Unified Naming convention 

5 

[0096] Given that 1MB service subscriber and, more generally, User Profile Database entries shall be uniquely iden- 
tified somehow with a logical name, this invention proposes what follows: 

1 . User Profile Database entries are uniquely identified by a Unified Name (UN), that is an E-mail address type- 
10 primary key; 

• for instance, a businessman can have an UN (e.g. john-d-smith-123@imb.sony.de), which is world-wide 
unique: the businessman can be reached on any of the terminal devices listed in his 1MB User Profile, by 
simply posting Instant Messages to the aforementioned UN; 

15 

2. User Profile Database entries are identified by users' personal information such as first, middle, and last name, 
date of birth, place of birth, home address, and the like. This information acts as secondary keys, whereas the UN 
acts as a primary key. Combinations of these properties (thereinafter, the properties) can thus be used for retrieving 
users' UNs upon third parties' demand; 

20 

3. the UNs are to be assigned by the authority that manages the Use Profile Database. In the simplest case the 
User Profile Database is actually owned by the 1MB Service Provider itself; 

4. the 1MB Service subscribers can use either their UN and/or individual/group aliases for being reachable via the 
25 1MB System. The UNs and the aliases (both implemented as strings of characters, but with the latter not bound to 

any specific schema) de facto hide the address of the current terminal device where the subscriber can be reached, 
thus abstracting out the technology used for delivering 1MB Services; 

5. as an 1MB System specific feature, User Profiles themselves can be assigned logical names (aliases), in order 
30 to improve the overall system usability, as perceived by subscribers. 

The User Profile Database structure 

[0097] The Default and the Extended User Profiles are implemented as sets of properties (cards), where each prop- 
35 erty key uniquely identifies a given property, and the property value corresponds to the given property content. 

[0098] Keys namespace depends on the card name, and eventually can include intra-set keys taxonomy (e.g. <a- 
1 t ully-quaiified-card-name>. terminal, speed would uniquely identify - within a given User Profile Database - a certain 
card containing, among others, the speed sub-property of the terminal property). 

[0099] These sets can be logically identified by names, which make use of the MASE Profile naming convention: 
40 names are a concatenation of (in order of appearance) LfeerName, 7e/777/na/Name, Network Name, Application Name, 
and Situation Name. 

[0100] In addition, a sixth name is hereby introduced, the Location Name, in order to convey information as to where 
the user is currently reachable. The location truly represents a physical location (e.g. a city, a hotel or an airport), 
whereas the situation represents a context (e.g. "home" Vs. "work"). The so modified MASE Profile paradigm is there- 

45 inafter indicated as Enhanced MASE Profile Paradigm , and abbreviated as EMPP. 

[0101] Figure 10 depicts how cards are actually organised in EMPP: the information is not stored in Default and 
Extended User Profile data structures, as originally proposed in the aforementioned logical data model. Rather, the 
Database content is stored in cards, which are logically grouped in a number of different ways. 
[0102] First of all cards can be organised in Card Types. A Card Type represents a set of default values that other 

50 cards can rely upon. Each Card Type maps uniquely to one of the aforementioned card name components. Cards 
within a Card Type can be logically organised in tree structures. 

[0103] For example, a pure terminal card (i.e. a card belonging to the Card Type Terminal) contains all the key/value 
pairs describing, a given terminal device: other cards can use such values for defaulting to any terminal specific property. 
[0104] By logically combining pure terminal cards (which altogether can be grouped in a T1 set, where the suffix 
55 indicates the number of card name components that are specified - in this case just one), one gets a new set of card, T2. 
[0105] T2 elements contain new and/or overriding information, which builds upon the T1 set elements. As stated 
above, T2 elements are logical combinations, and it is up to the Database Management System to properly enforce 
that T2 content defaults to the content of those T1 elements identified by the given card name. 
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[0106] For example, a T2 element containing a (User, Terminal) combination, specifies custom information about 
the terminal device to use, whereas user's and terminal specific information can be defaulted to the T1 elements 
containing respectively user's and terminal information. 

[0107] This process can be recursively iterated, until all the card names components are specified. Each step in the 
5 recursion identifies a set ranging from TO to T6, where TO represents the global system defaults (the default information 
describing the yet-to-be-configured system) and T6 represents the most specific information customisation. 
[0108] The concept of ate/ai//f information is thus implemented in a distributed fashion, by observing that: 

1 . certain information is exclusively managed by a specific actor (i.e. the user or the system administrator); 

10 

2. certain information is pertinent to a specific aspect of the service (i.e. the application used, or the context) 

3. this basic information can be further refined in intermediate defaults (T2, T3, T4, T5 sets); 

15 4. each actor may decide to customise information across the different defaults available (i.e. the TO set and all 

the intermediate ones). 

[01 09] This data model is very flexible, insofar as it is designed to address very complex scenarios, like distributing 
information over multiple networked HW units. On the other hand, this model is quite complex (see Figure 11), given 
20 that the number of elements in each of the Tx sets can be quite high (e.g. the T3 set features up to 20 combinations 
of card component names). However it is not mandated the use of all the possible Tx cards, and therefore it is up to 
the user and/or the system administrator to create as many tables as they may deem necessary. 



Implementing the 1MB User Profile Database with the Enhanced MASE Profile Paradigm 

25 

[0110] This paragraph finally explains how to map the data model represented in Figure 7 to the EMPP. The mapping 
is illustrated in Figure 12. 

[0111] The 1MB Account User Space and 1MB User Space can collapse together and be mapped to the T1 element 
with only the card component name Lteerspecified. In this card, among user's personal information, the Active Context 
30 Indicator can be implemented as a couple of key/value pairs: Current Location Indicator, and Current Situation Indicator. 
Either or both of them can be used to select the T2 element which specifies the current Active Context. 
[0112] The current Active Context deeply depends on both these concepts (as shown in Figure 12 with a multiple 
inheritance association among the Context (a logical representation of the physical and/or logical environment) and 
the T2 elements User-Location and User-Situation) because of the following reasons: 

35 

• the context may depend solely on the physical location, insofar as local authorities and/or organisations can cus- 
tomise 1MB services. For instance, a hotel can provide its customers - who happen to be 1MB service subscribers 
-with a set of terminal devices, where the customers can be reached in a more convenient and fast way -compared 
to the default set of terminal devices; 

40 

• the context may depend solely on the situation, which a subscriber happens to be in. For instance, the subscriber 
may be working on a meeting, on vacation, or performing some free-time activity. In either case, the situation may 
cause the 1MB system to deliver its service in to different set of terminal devices and with different policies (like 
deliver immediately or later); 

45 

• the context may depend on the combination of situation and location: a business meeting in a certain hotel, a 
business trip in a car, etc. Location -based contexts may imply situation -based contexts, and vice versa. 



[0113] Once the context has been selected (by identifying the User-Location and/or User-Situation cards), the 1MB 
50 subscriber can select the current terminal device where she/he would like to be reached with the highest priority. This 
is accomplished by using a key/value pair, the Current Terminal Indicator, which is contained in both the User-Location 
and User-Situation cards. Alternative available terminal devices are also listed in such cards: this list is used by the 
1MB MB for selecting alternative terminals where dispatch Instant Messages to. If the token multiplicity n is greater 
than one, the 1MB can select the first n elements in such a list and send copies of incoming Instant Messages to all 
55 the corresponding terminal devices. 

[0114] Finally more customised information can retrieved, by using theT4, T5, and T6. 

[0115] As a key feature, the EMPP allows users to implement their preferred search order, beyond the default one. 
[0116] As an optional feature in addition to the above mechanism, the EMPP also allows the enrich properties, by 



13 



EP 1 130 869 A1 



adding a specific resolution rule (attribute resolution rule) to each of them. This approach can be used for refining the 
search process across the overall set of EMPP cards, by specifying how default information can be overridden. Basi- 
cally, the key/value pairs are augmented with a new parameter, which indicates the rule to apply (thus leading to a 
logical key/rule/value triple). Such rules are as follows: 

5 

• Lock: the first occurrence of the given property found along a search run, is to be considered final, and the search 
process can be terminated. 

• Depending on the search order, this rule may lead to different results: 

10 

• as a typical case, if the search order examines first the most general occurrence of a property (e.g. from a TO 
to a T6 element), this will take precedence over any other more specific occurrence of the given property, 
which can be found afterwards along a search run; 

15 • as an exceptional case, if the search order examines first the most specific occurrence of a property (e.g. from 

a T6 to a TO element), this rule will produce the same results as the Override one (see below); 

• Override: the most specific occurrence of the given property, is to be considered final, and the search process 
can be terminated; 

20 

• Append: the union of the contents of all the occurrences of a given property, as found along a search run, is to 
be considered final. This rule makes sense only for certain type of properties (e.g. character strings). 

[01 1 7] The information about the resolution rule is actually linked to the property key, and is unique across the whole 
25 database. By changing rule, one basically creates a new property type, even if the key is the same. 
[0118] The overall EMPP can be implemented e.g. as a relational data base (see table I). 

[0119] Figure 13 exemplifies the 1MB Service usage by highlighting the mutable characteristic of the typical 1MB 
environment. 

30 The Units 

[0120] The 1MB Account Management functionality can be broken down into a set of co-operating SW Units, which 
can be distributed over multiple processes. These processes can be finally distributed over multiple HW Units (see 
Figure 6). At this extent, it may be advantageous the use of the MASE component architecture. This approach is based 
35 on ODP Engineering Viewpoint concept. 

[0121] The following paragraphs describe each of these SW Units in more detail. 

The 1MB Account Management Client Unit 

40 [0122] Subscribers can access their 1MB Accounting information (with read-only permission) and their 1MB User 
Profiles (with read-write permission), by using an 1MB Account Management Client Unit 

[0123] The counterpart of this Client Unit, the 1MB Account Management Server Unit, will be examined in the next 
paragraphs, broken down into several SW Units. 

[0124] This Client Unit can be located either directly on the terminal device the subscriber is currently using, or on 
45 a specific terminal device (e.g. a third-party's PC, in the case the subscriber had access only to dumb terminal devices 
like a Telefax machine). 

[0125] This Client Unit establishes a secure and authenticated connection with a MG (either directly, or e.g. through 
the mediation of a Web Server), forwards subscriber's requests to the MG, and finally presents results to subscriber 
as soon as the MG responds back to the request. 

so [0126] Finally, this Client Unit manages a logout procedure, either upon user's explicit request, or implicitly after 
expiration of a keep-alive timer. The keep-alive timer is re-set every time the user sends requests to the MG. 
[0127] This unit provides subscribers with a Ul for browsing 1MB User Profile and Accounting information. This Ul 
can be a standalone SW Unit (which the subscriber obtains at subscription time from the 1MB Service provider, and 
installs, on his/her PC/laptop/PDA), or can be accessed through the support of an 1MB Web Server, by using a COTS 

55 web browser. Alternative Ul implementations can be: 

• GUI 

• Web Interface (e.g. by using Java Servlet technology) 
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• SMS 

• WAP 

• Phone 

• Command-line (scripts) 
5 • Etc. 

[0128] In certain cases, where a terminal device does not offer a convenient and usable GUI solution, the Client Unit 
offers a limited set of its functionality. For example, a subscriber can use a GSM/SMS mobile phone for a limited set 
of functionality, like signalling online indication, downloading the list of 1MB User Profiles Names (aliases orcard names) 
10 from his/her 1MB User Space, performing a context switch, or simply querying IBM Accounting information. 

[0129] Moreover, such limited set of operations may even be requested by using many alternative technologies (e. 
g. speech recognition). 

[0130] Therefore this Client Unit functionality varies depending on the characteristics of the terminal devices used 
by the subscribers. 

15 

The 1MB Account Management Server Unit 

[0131] This Server Unit provides the functionality complementary to the 1MB Account Management Client Unit. 
[0132] This Server Unit, which de facto implements the hereby proposed Method, is a logical unit, insofar as it is 
20 further decomposed in a set of SW units that are distributed over multiple 1MB building blocks. These SW units co- 
operate in order to provide the desired 1MB Account Management Server Unit functionality. 

Message Gateway Account Management Server Unit 

25 [0133] Figure 14 offers an ODP Engineering Viewpoint of the Message Gateway. Following the ODP graphical no- 
tation and terminology, circles indicate physical basic engineering objects (i.e. the SW sub-Units, which the System is 
composed of). Rounded-angle boxes represent clusters (i.e. a set of closely related basic engineering objects grouped 
into a single memory address space). The grey-coloured rectangles represent physical channels, which abstract inter- 
cluster communications. These communications may span SW processes (through IPC mechanisms provided by the 

30 underlying OS) or HW devices (through networking). The Nucleus represents, in ODP terminology, the underlying OS. 
Double stroked arcs represent the interfaces among the various objects. 

[0134] At this level, no physical distribution of clusters among SW memory address spaces (also known as processes 
or, in ODP terminology, capsules) and HW Units (in ODP terminology also known as nodes) is hereby presented, since 
the 1MB architecture is quite modular. 
35 [0135] The figure actually represents an Originating MG (i.e. a MG configured to only process incoming requests to 
generate IMs). However, the core MG does not depend on the MG configuration. 

[0136] The MG Account Management functionality is located exactly in the core MG. The MG Account Management 
functionality models the MG 1MB Account Management Server Unit. 

[0137] This unit resides in the 1MB MG (see Figure 14), and deals with (i) secure connection establishment with the 
40 subscriber, (ii) subscriber's identity authentication, (iii) keep-alive timer management, and (iv) message relay from the 
subscriber to the 1MB MB, and vice versa. A web server can alternatively offer the first three functions. 
[0138] The MG communicates through secure IP connections with the MB Account Management Unit. 

Message Broker Account Management Unit 

45 

[0139] Figure 15 offers an ODP Engineering Viewpoint of the Message Broker and the 1MB Databases. The MB Co- 
ordination Function contains both the User Profile and 1MB Accounting Database Access Client Units; the User Profile 
DB and 1MB Accounting DB channels model respectively the channels between User Profile Database Access Client 
and Server Units, and between 1MB Accounting Database Access Client and Server Units. The DB Access Engineering 
50 Object that is present in both the User Profile DB and the 1MB Accounting clusters, accounts for COTS DB Management 
System-specific functionality, implementing the core of (respectively) the User Profile Database Access Server Unit 
and the 1MB Accounting Database Access Server Unit. 

[0140] This figure also depicts the IM Processing entity, which is in charge of special IM processing functionality. 
[0141] The MB architecture allows the designer to choose among many alternative implementations, depending on 
55 the requirements for the specific solution. It might in fact be useful to collocate the MB and the databases on the same 
node, or distribute them on multiple nodes, depending on administrative, cost, or performance factors that may vary 
from implementation to implementation. 

[0142] This SW Unit is located in the 1MB MB (see Figure 15), and maps subscribers' 1MB Account Management 
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operations to User Profile Database query update, creation, and deletion operations. The latter two operations are 
allowed only to authorised personnel: therefore, the MB Account Management Unit always verifies subscribers' au- 
thorisation level, in order to determine whether process or reject the requested operations. 

[0143] Moreover, this Unit maps subscribers' 1MB Account Management operations also to 1MB Accounting Database 
5 query operations. Accounting information is created and managed exclusively by the 1MB System in a protected man- 
ner. Only for exceptional cases (and with the authorisation of the corresponding subscribers), system administrators 
can be allowed to modify accounting information (e.g. in the case of a dispute over a bill). This SW Unit will therefore 
take care of providing accounting information update procedures only to authorised personnel. 
[0144] On the other hand, in order to protect subscribers' own sensitive and proprietary data (like passwords, secret 
10 keys, etc.) that are stored in either of the two aforementioned databases, system administrators/ 1 MB Service Providers 
should be prevented from performing any query and update operations on such information. 1MB Service Provider 
should be simply allowed to create and delete subscribers' sensitive information. For this purpose, the 1MB Service 
Contract shall make provisions of special rules for determining implicit contractual expiration terms, if any. 
[0145] Both this Unit and the core MB routing functionality use a couple of Database Access Client Sub-Units, one 
15 for the User Profile Database and one for the Accounting Database: each of these Sub-Units co-ordinates all the 
corresponding database accesses. 

[0146] This SW Unit finally manages the transmission of the results of the requested operations, back to the sub- 
scriber. 

20 User Profile Database Access Client Unit 

[0147] The MB Database Access unit communicates with the User Profile Database through a logical channel. This 
channel interfaces with the MB Database Access Unit across the User Profile Database Access Unit. Such SW Unit 
regulates channel access and encapsulate implementation details (which can vary, depending whether the database 
25 is accessed locally - e.g. through IPC mechanisms - or remotely - e.g. through TCP/IP connections). Irrespective of 
the channel implementation, any communications across it is guaranteed to be secure. 

1MB Accounting Database Access Client Unit 

30 [0148] The MB Database Access unit communicates with the 1MB Accounting Database through a logical channel. 
This channel interfaces with the MB Database Access Unit across the 1MB Accounting Database Access Unit. Such 
SW Unit regulates channel access and encapsulate implementation details (which can vary, depending whether the 
database is accessed locally - e.g. through IPC mechanisms - or remotely - e.g. through TCP/IP connections). Irre- 
spective of the channel implementation, any communications across it is guaranteed to be secure. 

35 

1MB Database Units 

[0149] These units contain the key information of the overall 1MB system, expressed in term of the EMPP data model, 
as described above. These SW Units can be implemented by either using COTS Database management systems, or 
40 as proprietary solutions. In either case, the most stringent requirement to cope with is the fact that 1MB Systems are 
envisioned to deal with large amount of traffic with extremely high availability constraints. Therefore COTS solutions 
are preferred, as they provide proven high performance solutions. 

[0150] The Databases are structured so as to accommodate the 1MB User Spaces, according to the EMPP model, 
into the specific technology of choice. For example, proper mapping of the EMPP to Relational Database models is 
45 envisioned to be the most common solution, given that many well known COTS solution implement , the relational 
model. Another alternative solution may be based on Sun Microsystems' (pure Java) Javaspace, a high-level process 
co-ordination tool based on the Tuple Space concept. 

[01 51 ] As an example, a possible mapping of the EMPP model to a Relational Database data model is offered in the 
following table: 

50 
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Table I: 





Example of EMPP Data Model flattening onto a single-table Relational Database 
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Key 
(P-key) 


Component Name 


Value 


10 


Key 
Name 


Key 
Resolution 
Rule 


User 


Terminal 


Network 


Application 


Situation 


Location 




terminal. 

monitor. 

speed 


Override 


Jack 


PDA xyz 


Wireless 
IP 


Calendar 


Work 


Dealer 
HJK 


9600 bps 


15 


terminal. 

monitor. 

speed 


Override 


Jack 


PDA xyz 


Default 


Default 


Default 


Default 


4800 bps 


20 


terminal. 

monitor. 

speed 


Override 


Bill 


Mobile 
Phone 


GSM 


Default 


On 
Vacation 


Lisboa 


2400 bps 




terminal. 

monitor. 

speed 


Override 


Default 


Mobile 
Phone 


GSM 


Default 


On 
Vacation 


Default 


1200 bps 


25 


terminal. 

monitor. 

size 


Lock 


Default 


Mobile 
Phone 


GSM 


Default 


On 
Vacation 


Default 


2" 



Example of EMPP Data Model flattening on a single-table Relational Database 

30 

User Profile Database Access Server Unit 



[01 52] The User Profile Database Access Server Unit communicates over secure data channels with the User Profile 
Database Access Client Unit, and provides the basic functionality for accessing the User Profile database through 
read-write operations. 

1MB Accounting Database Access Server Unit 

[0153] The 1MB Accounting Database Access Server Unit communicates over secure data channels with the 1MB 
Accounting Database Access Client Unit, and provides the basic functionality for accessing the 1MB Accounting, da- 
tabase through read-write operations. 

The main advantageous differences between the invention and the state of the art 
[0154] Following is a list of advantages offered by this invention with respect to the state of the art. 
1 . Direct access to personal 1MB User Profile information, including Accounting information. 



2. A customisable logical User Space, which subscribers can use for creating and/or modifying existing User Pro- 
5Q files, depending on the changes in the environment in which they act. The environment can represent a physical 

location (e.g. a hotel or an airport), or a logical context (e.g. "home" Vs. "work"). Environment changes may be a 
partial (whenever the set of terminal devices available in the environment, changes for some reasons - e.g. a new 
Telefax machine is made available, or a GSM phone number is changed), or global (the subscriber moves from 
one environment to another). 

55 

3. The original EMPP model is well suite for distributing information across multiple SW (processes, OS ) and/or 
HW Units (computers). 
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4. Subscribers can extend User Space content, as soon as terminal devices and/or new technologies are available. 

5. User Spaces can be seamlessly used across various environments. 

5 6. Within a given environment, subscribers can alter terminal device priority (which indicates to the MB which 

terminal device the incoming information should be preferably sent to), through the concept of presence token 
signalling. The token multiplicity can be greater than one, so that one can simultaneously receive an Instant Mes- 
sage on multiple devices, at an additional charge. 

10 7. More complex applications (like a calendar for generating appointment notices, wake-up calls, etc.) can be 

integrated within the 1MB System, by interfacing the latter with additional 1MB Units (performing the given applica- 
tion) and/or with COTS tools (such as Microsoft Outlook, continuing the calendar example). In such cases, appli- 
cation specific data should be introduced within the User Profile, so as to instruct the 1MB System how to use the 
external application for processing data. 

15 Another example of such plug-able applications would be the integration of a language translator: the 1MB MB 

will use an external translator application for determining the final content of the 1MB to send. In all these (and 
many other similar) cases, this invention plays a key role, insofar as the hereby-presented User Profile Database 
structure is flexible enough to accommodate any subscriber custom information, in a format which is well suite for 
a distributed processing environment, like the 1MB System is. 

20 

• By extending the rationale used in the previous paragraphs, 1MB subscribers can not only customise their 
applications of choice, but even name them with mnemonics, i.e. easy to remember logical names (e.g. 
my_calendar, german_to_english_translator, etc.) 

25 8. This approach paves the way to neat integration between 1MB Services and Mobile Ad-Hoc Network environ- 

ments: environment changes can be automatically detected and signalled to the 1MB System. This mechanism 
allows fast adaptive behaviour of the system, which can be compared somehow to the mobile phone hand-over 
mechanism. However, this invention addresses a much broader set of services than the pure telephone ones. 

30 Example 

[01 55] As described in the previous paragraphs, this invention copes with the need to address and exploit the mutable 
characteristics of a typical 1MB service scenario (also known as an 1MB mutable environment, see figure 13). 
[0156] 1MB subscribers can be contacted anywhere, insofar as they can travel (i.e. being reachable at different lo- 
ss cations/offices), and/or they can reconfigure their set of available terminal devices at any given time. 

[0157] In the example of figure 13 a Calling Party located in Moscow tries to send an IM to the businessman HJK (i. 
e. the Called Party), by connecting to the 1MB System through a web interface (by using a PC with an Internet access). 
The Calling Party does not know where the businessman is currently located. All the Calling Party knows is the busi- 
nessman's UN (e.g. HJK@sony.de). 
40 [0158] Based on the information stored in the User Profile Database, the 1MB System resolves the businessman's 
(i) Active Context and (ii) the current terminal device. 

[0159] Once got such information, the 1MB System can finally forward the IM (within the proper data format, as 
prescribed by the selected terminal device) to the Called Party. 

[0160] The Called Party can move to different locations (e.g. Company XYZ in Stuttgart), and orto different situations 
45 (on trip - he can use only a mobile phone and a wireless networked laptop - or at home). One can easily see why the 
Active Context is a loose concept. For instance, the home situation can span different locations: the businessman can 
choose that his Active Context home maps to his physical home and his office located in the Company XYZ premises, 
in Stuttgart. 

[0161] On the other hand, the hotel ABC in Los Angeles can become a new businessman's home for the whole 
50 duration of a certain business. Therefore, the businessman can decide to map a single location (hotel in Los Angeles) 
to two contexts, home (for private messaging), and on trip (for business matters). 

[0162] At any time, the businessman can use the hereby-presented invention to configure his 1MB User Profile; in 
order to address all these features. Moreover, he can force the 1MB System to redirect IMS to remote locations (e.g. 
send always a carbon copy of any incoming IM to the Telefax machine at the - physical - home). This goal can be easily 
55 accomplished by using the token concept. 
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Claims 

1 . Data base for storing and managing user profile data, 

the user profile data representing sets of terminal devices (9) of users in an information transmission network (10), 
wherein 

the data base (1) comprises respectively for each user at least one customizable user profile which can be 
created, edited and/or deleted by the user and 

each customizable user profile is associated with an environment of the user representing a physical location 
and/or a logical context of the user. 

2. Data base according to claim 1 , 
characterized in that 

the data base (1 ) comprises a plurality of user profiles for one user, wherein only one user profile of a user is active 
at the same time. 

3. Data base according to anyone of the preceding claims, 
characterized by 

one or a plurality of presence token for each user, each presence token representing the availability of a user to 
receive copies of incoming instant messages at one of the configured terminal devices (9). 

4. Data base according to anyone of the preceding claims, 
characterized by 

at least one default user profile for each user, wherein the default user profiles can not be deleted by the user. 

5. Data base according to claim 4, 
characterized in that 

the hierarchical scheme of the user profiles is a non-loop free tree, the user profile containing global system con- 
figuration being the root of such tree. 

6. Data base according to claim 5, 
characterized in that 

the customizable user profiles are sub trees of the global system configuration being topological^ equivalent to 
the global system configuration. 

7. Data base according to anyone of the preceding claims, 
characterized by 

a priority information associated with each terminal device (9) of a user profile. 

8. Data base according to anyone of the preceding claims, 
characterized in that 

the data base (1) contains information on the access network, the network address and 
the characteristics of each terminal device (9). 

9. Data base according to anyone of the preceding claims, 
characterized in that 

a mnemonic is attributed with each terminal device (9). 

10. Data base according to anyone of the preceding claims, 
characterized in that 

an unified name is attributed with each user. 

11. Data base according to anyone of the preceding claims, 
characterized in that 

the data base content is stored in cards in a distributed fashion. 

12. Data base according to anyone of the preceding claims 
characterized in that 
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an user can directly inquire accounting information. 

13. Software program implementing, when loaded in the memory of a computing device in a network environment, a 
data base (1 ) according to anyone of the preceding claims. 

5 

14. Method for managing a user profile data base (1) for storing user profile data representing sets of terminal devices 
(9) of users in an information transmission network (10), 

wherein the data base (1) comprises respectively for each user at least one customizable user profile which can 
be created, edited and/or deleted by the user and User Profiles are grouped in Contexts, where each Context is 
10 associated with an environment of the user representing a physical location and/or a logical context of the user. 

15. Method according to claim 14, 
characterized in that 

the data base (1) comprises a plurality of contexts for one user, wherein only one context of a user is active at the 
15 same time. 

16. Method according to claim 14 or 15, 
characterized by 

one or a plurality of presence token for each user, each presence token representing the availability of a user to 
20 receive copies of incoming instant messages at one of the configured terminal devices (9). 

17. Method according to anyone of claims 14 to 16. 
characterized in that 

at least one default user profile for each user is provided, wherein the default user profiles can not be deleted by 
25 the user. 

18. Method according to claim 17, 
characterized in that 

the hierarchical scheme of the user profiles is a non-loop free tree, the User Profile containing global system 
30 configuration being the root of such tree. 

19. Method according to claim 18, 
characterized in that 

the customizable user profiles are sub trees of the global system configuration being topologically equivalent to 
35 the global system configuration. 

20. Method according to anyone of claims 1 4 to 1 9. 
characterized by 

a priority information associated with each terminal device (9) of a user profile. 

40 

21 . Method according to anyone of claims 1 4 to 20. 
characterized in that 

the data base (1) contains information on the access network, the network address and 
the characteristics of each terminal device (9). 

45 

22. Method according to anyone of claims 15 to 21 . 
characterized in that 

a mnemonic is attributed with each terminal device (9). 

50 23. Method according to anyone of claims 1 4 to 22. 
characterized in that 

an unified name is attributed with each user. 

24. Method according to anyone of claims 1 4 to 23 ; 
55 characterized in that 

the data base content is stored in cards in a distributed fashion. 

25. Method according to anyone of claims 1 4 to 24. 
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characterized in that 

an user can directly inquire accounting information. 

26. Software program implementing, when loaded in the memory of a computing device in a network environment, 
method according to anyone of claims 1 4 to 25. 
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FIG 7 



<< domain >> 
1MB Service Provider 



IMs may eventually be generated ^ 
directly at the user side 



Instant Message 



>. 1 



Multimedia Flow/Stream 



A 



User Profile DB 



0.. 



1 



1MB Account 



+ActiveContextindicator: UserProfile 



1 



Billing 



Accounting DB 



1 



0.. 



Subscription 
*4 Contract 



1 



User Profile 
Space 



1 



Active 
Context 



1 



0.. 



I 



User Account 



1 



1.. 



Default User 
Profile 



t 



1 



0.. 



Token 



0..1 



Extended User 
Profile 

0. .*; Jj f_ 



User Profile 



Current 
Terminal 



1.. 



Terminal 



Device 



0.. 



1..* 11 



28 



EP 1 130 869 A1 




29 



EP 1 130 869 A1 



A 



CO 



CD 

o 

cd cd 



£5 cT"£ 

. 1 ^ « mm* ^^^^ _ 



eg 
"S3 



o 

CD 



O ^3 



O 
CD 



Q o o 





lane 


ser 1 








t: o ^ 



CD 

OS -O CO 



30 



EP 1 130 869 A1 



CD 

GO 




c3 "3 .23 55 
c in 



31 



EP 1 130 869 A1 



FIG 1 0B 

User Space 

T 6 = (X, Y, Z, W, J, K) : one 6-tuple 

T5 = {any combination of 5-tuple out of 1$ with one Default} : six 6-tuples 
T4 = {any combination of 4-tuple out of T§ with two Defaults} : fifteen 6-tuples 
T3 = {any combination of 3-tuple out of Tg with three Defaults} : twenty 6-tuples 
T2 = {any combination of 2-tuple out of Tg with four Defaults} : fifteen 6-tuples 
T-| = {any combination of 1-tuple out of T§ with five Defaults} : six 6-tuples 
Tq = (Def, Def, Def, Def, Def, Def} = Global System Default : one 6-tuple 
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